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REMARKS 

The pending claims were rejected under 35 (JSC 1 03(a). Applicant 
respectfully traverses the rejection. 

As articulated in the Advisory Action, the Examiner has interpreted the 
claims in a manner to eliminate a given element. Specifically, the Examiner has 
"construed* the programmer of Snell to be both the claimed programmer and the 
claimed monitor. The above amendments further specify that the monitor and 
the programmer are distinct and remote from one another. As this was always a 
feature of the claims and was simply being selectively ignored by the Examiner, 
these amendments do not serve to narrow the claims. 

Applicant is somewhat amazed by the argument presented in the Advisory 
Action that Snell "fails to articulate the origin of the request." The Examiner is 
reminded that a given reference must be considered in its entirety. MPEP 
2141.02. ("The network server 102 includes components for receiving commands 
and data from the network programmers 104. Col. 4, lines 55-57.) Furthermore, 
the Examiner's "modification* may not change the principle of operation of a 
reference. MPEP 2143.01 . Only by selectively and inappropriately ignoring the 
fact that Snell teaches a physician interface with the programmer and that the 
programmer communicates with the server can the Examiner construe into 
existence a "problem" to be solved via a combination with Brown. As this is 
explicitly precluded by the rules of practice, the rejection is wholly improper and 
must be withdrawn. 

Of notable concern, the Examiner has mischaracterized statements made 
by Applicant. Specifically, the Examiner states "applicants secondly assert that 
Snell lacks the ability to transmit such a request." Applicant must insist that this 
statement either be corrected or that the Examiner provide a basis in the formal 
record for such an assertion. As previously stated and repeated below, the 
programmer of Snell provides a means to communicate with the server. 

By way of example, claim 1 relates to an apparatus for programming an 
implantable medical device (IMD). With that apparatus a clinician uses a 
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programmer (A) to create a request to modify the IMD. That request is sent from 
the programmer (A) to the server (B). A monitor (C) that is remote from the 
programmer (i.e., the monitor is not the programmer) receives the request from 
the server (A), and the monitor (C) then transmits that request to the IMD. Thus, 
the clinician uses A, to communicate with B, B communicates with C and C 
communicates with the IMD. A and C are not the same element. 

Snell lacks the claimed monitor, among other things. Applicant must 
respectfully assert that the Examiner's dismissal of this fact based on whether "a 
difference in name" is distinguishing is entirely unsupportable. The Snell system 
alone does not anticipate the claims, nor render them obvious either alone or 
combined with the references of record. 

In Snell, the clinician interfaces exclusively with the network programmer 
104 and the network programmer 104 is the exclusive component that 
communicates with the IMD 105; thus, it is proximate the patient with the IMD. 
The network server 102 is only used to provide more computing power to the 
network programmer 104. Thus, whether software is updated via this 
arrangement (Col. 5, lines 29-34) or "generates" the programming commands 
(Col. 5 lines 60 - Col. 6, lines 15) based upon what the clinician enters at the 
network programmer 104, the result is the same. This is a system where the 
clinician has a device next to the patient and operates to effect programming 
changes at that location. 

In order for the Examiner to construe Snell to teach the claimed apparatus 
(forgoing a consideration of Brown, for the moment) the clinician must use the 
network programmer (A) to create and communicate a request to the network 
server (B), the network server (B), sends this request back to the very same 
network programmer (A) which now is considered a different element or monitor 
(C) and the network programmer (A)/monitor (C) communicates with the IMD. Of 
course, in Snell there is no monitor (C) and the lack of this element is more than 
a "naming" issue. 
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In Snell, where the network programmer 104 is capable of creating the 
request, as claimed, then the device is acting as a stand-alone programmer and 
only relying on the network server for software upgrades, database access, etc. 
Alternatively, Snell explicitly states that the physician communicate with the 
network programmer (Col. 5, line 67) and that everything generated by the 
network server (102) is subject to "physician control" (Col. 6, lines 2-3). Thus, 
the physician uses the network programmer 104 to control what is sent to the 
IMD. In order to do so, the commands generated by the server are sent to the 
physician at the network programmer. 

In other words, Snell does not contemplate, teach or allow for remote 
programming of the device. The physician's presence is explicitly required at the 
patient's site and at the network programmer's site. The Examiner is 
conveniently and inappropriately removing the fact that the physician uses the 
network programmer 104 to generate the request. The reference must be 
considered as a whole and in its entirety. There is no basis for removing the 
physician from interfacing with the network programmer or adding another 
interface at a different site and reclassifying the network programmer from what 
Snell teaches to the claimed monitor. Furthermore, Snell explicitly teaches away 
from this by indicating that the physician maintains control and must approve 
what is passed to the implantable medical device (Col. 6, lines 2-4). This issue 
was not addressed in the Advisory Action. 

Despite this, the Examiner has attempted to combine Snell with Brown. 
Brown teaches providing software updates to external glucose monitors. The 
Examiner's rejection asserts that there is no "programmer through which the 
physician creates the request" taught in Snell. Applicant is somewhat surprised 
to learn (that the Examiner believes) that Snell fails to provide a means by which 
the physician can create a request since the entirety of the Snell reference is 
directed to "a distributed system of network programmers" which by necessity 
require such input. 
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Of course, network programmer 104 is where the physician creates the 
request. In most embodiments of Snell, the network programmer 1 04 is a 
complete standalone programmer and when not relying on the server for 
processing capability, there is still no "monitor" in the reference. Rather, the 
network programmer 104 has been renamed as a "monitor" solely for purposes 
of this rejection. Specifically, the Examiner asserts "Snell teaches the physician 
sending the request through the server 102 to the monitor 104, but lacks a 
programmer through which the physician creates the request." This overlooks 
the fact that the network programmer 104 (now named the monitor) is the 
physician interface and the information generated by the server is sent back to 
this exact same device. Applicant respectfully asserts that Snell lacks a monitor 
as claimed and lacks the claimed interrelation between the elements; a 
programmer is in fact provided and it accessed by the physician. The 
programmer is either network programmer 104 acting as a stand-alone 
programmer or network programmer 104 using server 102 for computational 
purposes. In no case is there a lack of a programming interface as purported by 
the Examiner. 

Next the Examiner explains that Brown teaches a "programmer 62." Of 
course, this is not a programmer for an implantable medical device as presently 
claimed or as used in Snell, but merely a personal computer by which a doctor is 
able to send messages to a patient. In addition, the Examiner relies on Brown to 
teach "authorization codes." 

Thus, the Examiner's rejection proposes to modify Snell by adding the 
Brown "programmer" because Snell "teaches a system in which a server is 
capable of receiving a request from a clinician and Brown '563 describes an 
appropriate system for transmitting such a request/' In addition, the "combination 
would additionally maintain appropriate safety levels." This is purportedly the 
statutorily required motivation to combine references. Applicant respectfully 
traverses. 
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First, Snell does not lack the ability to transmit such a request; rather such 
a system is explicitly provided in context. Second, the ability to make a 
combination is not a motivation to do so. Third, a computer messaging system 
utilizing a physician's PC does not teach a programmer capable of interfacing 
with and programming an implantable medical device. Fourth, safety (in the 
authorization sense) is not at issue as the physician is controlling the network 
programmer in proximity to the patient as explicitly required by Snell. Any 
security protocols present exist at the network programmer. Fifth, the Examiner 
has proposed a modification with the motivation being a means to address a 
problem created solely by the modification. The Examiner is making the 
combination to craft a rejection based on the absence of a "programmer" in Snell. 
The Examiner has failed to indicate why such a modification would be motivated; 
rather, has explained that if made, Browns authentication would be useful to the 
modified system. 

The present claims are directed to systems and methods that facilitate 
remote programming on an implantable medical device, Snell does not teach the 
claimed elements. Brown is wholly irrelevant, as it does not address 
programming of implantable medical devices. The combination of these 
reference is inappropriate and unsupportable and even if made, does not teach 
the claimed invention. For these and other reasons, the rejections must be 
withdrawn. 



Respectfully submitted, 
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